1. Field of the Invention
The present invention provides a mechanism that arbitrarily consumes RAM memory on an associated server in a measurable and demonstration-friendly way.
2. Description of Related Art
A need arose to properly display the capabilities of the Unisys Server Sentinel suite of tools from the desire to be able to predictably trigger recovery events in a cluster load balancer environment. This need arose because it was necessary to create an application that would consume a pre-determined amount of memory at a pre-determined rate. Without this invention, it would be necessary to simply wait for a memory problem to occur. This may or may not ever happen naturally. Essentially, there was a need to be able to trigger events at any given moment, with a great deal of precision. During the rollout of the Unisys Dylan system, marketing wanted to be able to demonstrate the features included in a solution named “Application Sentinel”. One of the features of application Sentinel is its ability to detect “rogue applications”. These are applications that are consuming too many resources (such as memory or CPU time). When Application Sentinel sees a rogue application, it shuts it down and restores the monopolized resources to the system. The present invention simulates the conditions created by a rogue application, thus allowing the components of Application Sentinel to be demonstrated. A similar scenario can be concocted to explain the use of this invention in testing of development scenarios. If it is required that a rogue application be simulated to test the correctness of a software, this invention can also be used.
The Unisys ES7000 server is an Intel and Windows-based, partitionable, vertically scalable machine. The Unisys ES7000 server has proven ideal for general-purpose Windows server use for business intelligence and other applications, mission-critical data center use employing Windows Datacenter software, high availability and scalable clusters, server consolidation, disaster recovery, and more.
The solution for this problem (of finding applications consuming too many resources) began with creating a video playback mechanism. The reason video playback was incorporated was because the memory consumption application was intended to emulate a generic application that had “Gone rogue” and which was consuming memory rapidly. By including a video component, it was believed that the people viewing a demo, that included this technology, would, not only be visually pleasing, but also intuitively plausible as revealing a “memory consumer”. Another way that the present invention is helpful is that it allows a user to simulate the persistence of a program state. “Program state” is the condition that a piece of software is in at any given time.
For example, a program could be open, with three particular files open within it. That is one state. If a user closed one file within the program, this would represent a different state. In general, programs have an infinite variety of states they can be in. When a computer program experiences an error and is forced to close down by either the operating system or another program, the program state is often lost. For example, if you are using a word processing program and do not save your work, a power outage will cause all of your work to be lost. Your word processor did not “persist” the program state.
The present invention simulates how a “program state” can be persisted in a crisis situation. If the software is closed by another piece of software, it can then be re-launched with the original program state still intact. By “original program state”, it is meant to show the state that the program was in, immediately before it was forcefully shut down. Within the application, API calls were made that would arbitrarily consume memory at intervals determined by the user. The memory that is consumed is located in what is called the “heap”. This is the place that dynamically created objects reside. Physically, this is RAM that is located on the motherboard of the computer in question. The user is empowered to not only chose the speed at which memory is consumed, but one can also set the amount of memory (in bytes) that is to be consumed at each interval of time. This allows an operator (with some experimentation) to predict the exact moment at which a memory threshold will be reached, which will cause a failover reaction.
This invention is useful because it allows an individual to manually trigger the execution of Unisys products contained in different software packages. In typical data center environments, it would be difficult to demonstrate some of the functionality of other Unisys software which typically would lay dormant until a catastrophe has arisen. This present software creates a catastrophe that other software responds to. By manufacturing a crisis, Unisys sales people and employees have the opportunity to display the capabilities of operating software, and to test them.